Field of the Invention
The present invention relates to processors. More particularly, the present invention relates to providing a level of assurance that a processor is executing trusted firmware/software, particularly in integrated circuit processors that have insufficient built-in protection.
Description of Related Art
Hacking of embedded processor based systems is on the rise. It is easy to obtain many embedded products. Tools for hacking such systems are readily available from hacker websites. Improved security measures are required to counter these increasingly sophisticated attacks.
In the context of this invention, “processor” refers to an electronic circuit that is programmed or configured with object code (for example, a compiled program including any associated data) or a bitstream (for example, a compiled logic design including any associated data) that is loaded into the circuit that customizes the run-time operation of the circuit. Some types of processors envisioned for use in the invention include, without limitation, single or multi-chip microprocessors (MPUs), microcontrollers (MCUs), digital signal processors (DSPs), graphics processors (GPUs), network processors (NPUs), field programmable gate arrays (FPGAs), system-on-chip (SoC) integrated circuits, or any combination of these such as SoC FPGAs and multi-processor integrated circuits and systems. “Code” is subsequently used to refer to the object code, bitstreams, or associated data that is loaded into the processor during the initialization and start-up of the circuit, commonly referred to as the boot-up phase. Code may also be loaded in later phases, particularly if the entire program cannot fit into the processor at one time due to capacity limitations of the processor.
The cornerstone of embedded system security is to ensure that only authorized processor code is loaded and executed. System security begins with initial power-on processor boot code. The process of guaranteeing the execution of authentic code is commonly called “Secure Boot”. If the initial hardware and boot code can be trusted, then this trust can be extended to code loaded and executed later by using cryptographic techniques such as digital code signing. No single technique will prevent compromise; security must be built up in layers upon a secure foundation. The secure foundation is the Root of trust, and starts with secure hardware.
Many unsecured processors import all instruction code from off-chip, beginning from the first instruction executed. For example, they may request the data in address zero of an off-chip non-volatile memory, like a flash PROM, and use that as the first instruction to be executed. If it is not a branch instruction, the instruction counter automatically increments and the next word fetched and executed, ad infinitum. No authentication on the code that is fetched is done. Obviously, all an adversary has to do in this case to subvert the process is to change the PROM having the desired firmware to one containing his malicious code, or to intercept the code at the circuit-board level and replace the legitimate code with his malicious code. In some cases, an adversary may attack an embedded processor system over a network, and then by “re-flashing” the system (i.e., updating the contents of the PROM), he can make his exploit persistent. Secure Boot can detect such a change in the boot PROM the next time the system is reset and rebooted, thus providing added security even against network-based attacks.
FIG. 1 is a flow diagram depicting a typical prior-art unsecure boot sequence 10. In Phase 0 at reference numeral 12, an on-chip boot ROM fetches an application-specific secondary boot loader from external memory. Phase 1 is an application-specific boot loader shown at reference numeral 14. The BIOS, to the extent that it exists for a given implementation, is then loaded in Phase 2 as shown at reference numeral 16. The operating system is then loaded in Phase 3 as shown at reference numeral 18. Finally, in Phase 4, applications are loaded as shown at reference numeral 20.
Execution from the first phase, Phase 0, to Phase 4 is non-stop. This non-stop execution is unsecure because during execution of any of Phases 1 through 4, a hacker may substitute unauthorized code in place of the code that is meant to be executed by the processor, and it will be executed by the processor without being checked for authenticity.
Securely booting non-secure processors is challenging when the target processor has no built-in security capabilities. There is no root of trust capability in such systems. Customers in many market segments, such as telecom, military, industrial, medical, and energy, face this issue. Smaller microprocessors/microcontrollers are often located in peripheral or remote subsystems. These processors typically have no security capability and are especially vulnerable to attack.
FIG. 2 is a flow diagram depicting a prior-art secure boot sequence. In FIG. 2 the system is initialized from rest with trusted code. Phase 0 boot is performed by an immutable boot loader. The initial root of trust in this process stems from immutable trusted hardware.
In the boot sequence depicted in FIG. 2, validation of each stage is performed by the prior stage. The code for Phases 1 through n is validated by an already-trusted system before execution is transferred to it. This process establishes a chain of trust all the way to the top application layer.
Some processors may nominally include a secure boot capability, such as depicted in FIG. 2, where off-chip code is authenticated when loaded and before execution, but the capability may not meet the (higher) security demands of a particular application. For example, the built-in secure boot capability may be vulnerable to having its secret keys extracted using a side channel analysis (SCA) technique such as simple power analysis (SPA), differential power analysis (DPA), or differential electro-magnetic analysis (DEMA). Especially in fielded or remote systems where the adversary may gain physical proximity to the system, threats, such as these, may be unacceptable to the system designer because if the adversary can learn the values of the secret keys he can defeat the secure boot implementation by making his own malicious code appear authentic to the processor, which will be tricked into executing the forged code.